Hmm. I think that should not be the case - at least by default when Airflow imports Dags (whether it's in Triggerer, worker or Dag Processor), it should add bundle root to the PYTHONPATH automatically - and we should avoid adding it externally- if we see a problem that it is not added, we should fix it.

@jedcunningham @ephraimbuddy - am I right ?

Correct (edit: mostly). In fact, triggers from Dag files was pretty broken before anyways, so we intentionally removed that ability in AF3.

edit:

whether it's in Triggerer, worker or Dag Processor), it should add bundle root to the PYTHONPATH automatically

Yes for worker and dag processor. But not for the triggerer - the single process architecture means you can't do it reliably.

See #48603.

Thanks Jarek and Jed for sharing the context.

I think there two parts we pointed out here

1. Whether the triggers are importable in Dag files
2. The refreshing mechanism for triggers

if we see a problem that it is not added, we should fix it.

Agreed.

For first part:

Even though it's pointed out as bad practice as This just formalizes that it's best practice to have triggers come from elsewhere on sys.path instead to avoid that problem. in #48603

From the user perspective, I would expect my triggers defined in Dag files could be imported by Triggerer, but the Triggerer doesn't respect AIRFLOW__CORE__DAGS_FOLDER currently.

In fact, triggers from Dag files was pretty broken before anyways, so we intentionally removed that ability in AF3.

We are able to restore the importing triggers from Dag files by adding sys.path.insert(0, conf.get("core", "dags_folder")) before entering Triggerer's async loop.

as the triggerer is unable to account for changes without having a restart.

Then this level of problem will be second part:

Unless we refactor Triggerer to run the triggers by execution_time/task_runner instead of running them as pure asyncio coroutines, we will not be able to make the Triggerer aware of the Dag Bundle. This will need much more discussion and effort and might not be finished soon.

Thanks again for sharing the context! I will workaround with /files/airflow-breeze-config/environment_variables.env for now, as defining triggers in Dag files is not best practice and restoring Triggerer aware of the Dag Bundle will not happen soon.

Even though it's pointed out as bad practice as This just formalizes that it's best practice to have triggers come from elsewhere on sys.path instead to avoid that problem. in #48603

From the user perspective, I would expect my triggers defined in Dag files could be imported by Triggerer, but the Triggerer doesn't respect AIRFLOW__CORE__DAGS_FOLDER currently.

Don't focus as much on my PR description, but the changes in the PR. It's not just "best practice" not to in Airflow 3, we intentionally removed the ability to have them in a dag file.

Also, don't focus on "dags folder" - you must have a multi-bundle mental model now. The "dags folder" config is simply a default for familiarity sake. It is completely valid to have a deployment that does not use [core] dags_folder at all, and any change referencing it directly should immediately raise a yellow flag :)